Dieses Programm ist Freeware. (C) 1996 Richard Atterer
Beim Verbreiten dieses Programms darf kein Gewinn gemacht werden; wird Geld für die Weitergabe verlangt, darf der Betrag die entstehenden Unkosten nicht übersteigen. Um das Programm als ‘Extra’ zusammen mit kommerzieller Software, mit einem Magazin o.ä. zu verbreiten, bedarf es der vorherigen schriftlichen Einwilligung des Autors.
Es müssen stets alle Dateien des Programms weitergegeben werden.
Benutzung auf eigene Gefahr! Für eventuelle Schäden, die durch die Benutzung des Programms entstehen, auch wenn sie durch Fehler im Programm oder in der Anleitung verursacht wurden, übernimmt der Autor keine Haftung. Es wird nicht garantiert, daß das Programm für eine bestimmte Aufgabe nützlich ist.
1.2. Kurzbeschreibung
———————————————————————
MyMenu ist ein Programm, das es dir auf einfache Weise erlaubt, selbst ein beliebiges Menüsystem aufzubauen. Jeder Menüeintrag führt, wenn er angewählt wird, eine oder mehrere *commands aus (man kann z.B. Verzeichnisse öffnen oder Programme starten). Außerdem kann man beliebige Tastenkombinationen (auch Maustasten!) als ‘Hotkeys’ definieren. Werden die Tasten gedrückt, öffnet sich entweder das entsprechende Menü oder die Befehle des jeweiligen Menüeintrags werden ausgeführt.
Keine Angst, wenn du von *commands (sprich: ‘star commands’) keine Ahnung hast — die wichtigsten Befehle werden weiter unten beschrieben!
Da MyMenu ständig im Speicher sein muß, damit es die Hotkeys abfangen kann, wurde besonderer Wert darauf gelegt, daß es sehr sparsam mit dem Speicherplatz umgeht. So werden, wenn das Menü erst bei Bedarf nachgeladen wird (es kann auch ständig im Speicher bleiben) gerade mal etwas mehr als 2,6 kBytes benötigt, egal, wie groß das Menü ist.
1.3. Wann ist es nützlich?
————————————————————————————
• beim Starten von Programmen — wenn du z.B. nur noch ‘Alt Print’ drücken mußt, um deinen Druckertreiber zu laden, oder eines deiner 50 Lieblingsprogramme mit zwei Mausklicks auf die Icon bar holen kannst, ohne vorher die 49 anderen, die sich im selben Verzeichnis befinden, booten zu müssen
• wenn du ein CD ROM-Laufwerk hast — du kannst die wichtigsten Verzeichnisse/Programme auf deinen CDs in dein Menü aufnehmen und vermeidest damit, daß du dich andauernd durch zahlreiche Verzeichnisse kämpfen mußt. Dasselbe gilt natürlich auch für Festplatten.
• bei umfangreichen Diskettensammlungen (v.a. für Benutzer ohne Festplatte)
• für andere Dinge, die du sonst immer wieder ‘von Hand’ machen mußt — z.B. wenn du, bevor du dein Textprogramm lädst, in eine bestimmte Bildschirmauflösung umschalten, zusätzliche Fonts anmelden, den Font Cache vergrößern, !Chars starten willst etc. etc.
1.4. Benutzung
————————————————
MyMenu benötigt RISC OS 3.00 aufwärts. (Es wurde unter RISC OS 3.11, 3.6 und 3.7/StrongARM getestet.)
Wenn das Programm mit einem Doppelklick gestartet wird, scheint gar nichts zu passieren, da MyMenu kein Icon auf der Icon bar installiert. Dementsprechend kann es auch nicht auf die sonst übliche Weise im Icon bar-Menü beendet werden, sondern dies muß vom Fenster des Task-Managers aus geschehen.
Unter RISC OS 3.11 ‘überlebt’ MyMenu weiche Resets (d.h. Shift Break oder Reset-Taster ohne weitere gedrückte Tasten). Leider sind weiche Resets in RISC OS 3.5 und später abgeschafft worden... [FUNKTIONIERT LEIDER MOMENTAN NOCH NICHT RICHTIG]
Am Anfang ist ein Beispiel-Menü vorhanden, das du natürlich nach Belieben ändern und erweitern kannst (bzw. sogar sollst!) — wenn du aber MyMenu an Andere weitergibst, sollte immer das ursprüngliche Menü dabeisein. Die in diesem Beispiel definierten Hotkeys erlauben es, die ROM-Applikationen zu starten, indem man Alt zusammen mit dem Anfangsbuchstaben der jeweiligen Applikation drückt, das Menü wird geöffnet, indem man MENÜ klickt, während sich der Mauszeiger am linken Bildschirmrand befindet.
2. Die Menü-Datei
=====================
2.1. Einleitung
—————————————————
Das Aussehen des gesamten Menüs wird in der Textdatei „Menu“ beschrieben, die sich im Verzeichnis „!MyMenu.Menu“ befindet. Im gleichen Verzeichnis ist auch noch die Datei „MenuScan“, in der die in der Menü-Datei enthaltenen Informationen gespeichert werden. Sie wird automatisch von MyMenu erzeugt, damit das Nachladen des Menüs schnell vonstatten geht. Die Interpretation der Menü-Datei selbst kann nämlich bei (sehr) großen Menüs durchaus eine Sekunde und länger dauern, was lästig sein kann. Dadurch, daß die Menüdaten vorher in einem von MyMenu direkt verwendbaren Format gespeichert werden, muß der Teil des Programms, der die Interpretation besorgt, auch nicht die ganze Zeit über im Speicher sein, so daß knapp 5 kByte gespart werden. Änderungen der Menü-Datei werden deswegen aber auch nur erst dann erkannt, wenn MyMenu neu gestartet wird. Dazu muß man nur „!MyMenu“ erneut doppelklicken. Den gleichen Effekt hat ein Doppelklick auf „RescanMenu“, das sich im gleichen Verzeichnis wie die Menü-Datei befindet.
(Das Programm findet übrigens heraus, ob „MenuScan“ aktualisiert werden muß, indem beim Starten geprüft wird, ob es die gleiche Datestamp wie „Menu“ hat.)
2.2. Syntax
—————————————
Beim Interpretieren wird die Menü-Datei „Menu“ zeilenweise abgearbeitet, wobei Leerzeilen sowie Zeilen, die mit | beginnen (Kommentarzeilen), ignoriert werden. Grundsätzlich darf in jeder Zeile nur ein Befehl stehen. Leerzeichen vor oder nach Befehlen (außer bei den *commands) sind nicht erlaubt.
2.2.1. Befehle vor Menü-/Menüeintrags-Definitionen
Bevor die Definitionen für die Menüs und Menüeinträge beginnen, können noch andere Befehle in der Datei vorkommen:
Special:*
Mit dieser Zeile, die unbedingt in der Datei stehen muß, wird ein Spezial-Zeichen definiert (in diesem Fall * ), das bei den nachfolgenden Menüdefinitionen eine besondere Rolle spielt. Normalerweise dürfte es nicht nötig sein, ein anderes Zeichen als * zu verwenden, aber dies kann der Fall sein, wenn man andernfalls gegen die folgenden Einschränkungen verstoßen würde:
• Das Spezial-Zeichen darf nicht in Menünamen vorkommen.
• Es darf nicht das erste Zeichen eines Menüeintrags sein.
• Keiner der *commands darf mit dem Spezial-Zeichen beginnen.
LoadOnDemand
Ist dieser Befehl nicht vorhanden, wird die Datei „MenuScan“, die das Menü enthält, beim Starten von MyMenu geladen und bleibt dann andauernd im Speicher. Ist er dagegen vorhanden, wird „MenuScan“ erst ‘bei Bedarf’ geladen, d.h. dann, wenn eines der definierten Menüs angezeigt oder die *commands für eine Tastenkombination ausgeführt werden sollen. Sobald das Menü wieder vom Bildschirm verschwindet oder der letzte der *commands ausgeführt worden ist, werden die Menüdaten wieder ‘vergessen’ — sie müssen also jedesmal neu nachgeladen werden. Aus diesem Grund sollten Benutzer, die keine Festplatte besitzen, „LoadOnDemand“ nicht verwenden, alle anderen können es tun, wenn sie meinen, daß ihr Menü zuviel Speicherplatz verbraucht. (Der beanspruchte Speicherplatz ist so groß wie die Dateigröße von „MenuScan“.)
BufferAll
Diese Zeile, falls vorhanden, bewirkt, daß sich das Programm so verhält, als hätte jeder der in der Datei folgenden Menüpunkte einen „B“-Zusatz — es wird ignoriert, ob dieser tatsächlich vorhanden ist oder nicht. Der „B“-Zusatz ist weiter unten beschrieben.
Ich empfehle dringend, „BufferAll“ auf jeden Fall zu verwenden, wenn „LoadOnDemand“ verwendet wird — ansonsten sind nämlich zwei Dateizugriffe nötig, um *commands auszuführen.
Nach den oben beschriebenen 1−3 Befehlen dürfen nur noch Menü- und Menüeintrag-Definitionen in der Datei folgen.
Hinweis: Die folgenden Beschreibungen gehen davon aus, daß das Spezial-Zeichen als * definiert worden ist. Wenn das bei dir nicht der Fall ist, mußt du natürlich das von dir gewählte Zeichen anstelle von * verwenden.
2.2.2. Menü-Definitionen
------------------------
Menüs werden definiert durch:
**Menüname*
Man kann auch mit einem Befehl ein Menü und gleichzeitig ein Untermenü dieses Menüs definieren:
**Menüname*Untermenüname*
oder
**Menüname*Untermenüname*Unter-Untermenüname*
und so weiter. Zu beachten ist, daß vor dem ersten Menünamen ** stehen muß und nach jedem Menünamen ein einzelnes *
Es ist ohne weiteres möglich, in späteren Menüdefinitionen bereits vorhandene Menüs zu nennen. Die Zeilen:
**MyMenu*Gfx & Sound*Graphics*
**MyMenu*Gfx & Sound*Sound*
erzeugen vier Menüs: „MyMenu“, „Gfx & Sound“, und als Untermenüs von „Gfx & Sound“ die beiden Menüs „Graphics“ und „Sound“.
Diese Art, die Menüs zu definieren, bedeutet im Grunde, daß man jedes Menü anhand seines ‘Pfades’ innerhalb der gesamten Menüstruktur definiert, ähnlich wie bei Pfadnamen von Dateien.
2.2.3. Menüeintrags-Definitionen
--------------------------------
Menüeinträge werden definiert durch
*Menüeintrag-Name*
<gefolgt von einer oder mehreren Zeilen mit *commands>
Der Menüeintrag-Name kann das Zeichen * enthalten, allerdings nicht am Anfang. „*File $.M**“ ist möglich (ergibt den Eintrag „File $.M*“), „**Info*“ dagegen nicht — dies würde als Menüdefinition interpretiert werden und nicht als Eintrag „*Info“.
Das Ende der Zeilen mit *commands wird dadurch erkannt, daß das erste Zeichen der folgenden Zeile ein * ist (oder natürlich, daß das Ende der Menü-Datei erreicht ist).
Im Gegensatz zu den Menüs wird bei den Menüeinträgen nicht der volle ‘Pfadname’ angegeben. Stattdessen wird der Eintrag in dasjenige Menü aufgenommen, das in der letzten Menüdefinitions-Zeile genannt worden ist. Am einfachsten läßt sich dieses Prinzip mit einem Beispiel demonstrieren:
Diese Zeilen: ...erzeugen diese Menüstruktur:
**MyMenu*
*Sag Hallo*
Echo Hallo +———————————+
**MyMenu*Apps* | MyMenu |———————————+
*Chars* +———————————| Apps |
ChangeDynamicArea -fontsize 128k | Sag Hallo |———————————+
/Resources:$.Apps.!Chars | Apps =>| Chars |
*ChangeFSI* | Mode 31 | ChangeFSI |
/<ChangeFSI$Dir> +———————————+———————————+
**MyMenu*
*Mode 31*
WimpMode 31
Beachte, daß die Reihenfolge der Einträge in den Menüs davon abhängt, welcher von ihnen zuerst in der Menü-Datei auftaucht. Das gilt auch für diejenigen Einträge, die bei der Definition eines Untermenüs entstehen: Im obigen Beispiel wird das Untermenü „Apps“ erst definiert, nachdem „Sag Hallo“ im Hauptmenü eingetragen worden ist, deswegen steht der Menüeintrag, der das „Apps“-Untermenü öffnet, auch erst an zweiter Stelle.
Übrigens ist es völlig egal, wie oft in der Menü-Datei zwischen verschiedenen Menüs ‘hin- und hergeschaltet’ wird (in unserem Beispiel zuerst „MyMenu“, dann „Apps“ und schließlich wieder „MyMenu“) — dies hat keinerlei Einfluß auf die Größe von „MenuScan“ und damit auf den Speicherverbrauch.
2.2.4. *commands, die den Eintrags-Definitionen folgen
Durch das Beispiel wird auch deutlich, wie die *commands eines Eintrags aussehen können. Hinter jedem Eintrag muß mindestens eine *command-Zeile folgen. Kommentar- und Leerzeilen, die sich auch zwischen *commands befinden können, werden schon bei der Interpretation der Menü-Datei ignoriert, so daß sie nicht als Befehlszeilen gelten.
Noch einige Hinweise für fortgeschrittene Benutzer:
• Die *commands werden nicht so ausgeführt wie in einer Obey-Datei, sondern so wie in einer Desktop-Datei — also nicht mit OS_CLI, sondern mit Wimp_StartTask. Der Grund dafür ist, daß es sonst sehr leicht zu Abstürzen kommen kann, z.B. wenn ein Programm mit Run gestartet werden soll (es würde dann in den Speicher des gerade eingeblendeten Programms geladen!). Außerdem würde ein Obeyfile noch lange nicht allein dadurch simuliert, daß man die Befehle mit OS_CLI ausführt. Um es zu simulieren, müßte ein Befehl, den MyMenu bereitzustellen hätte, mit Wimp_StartTask aufgerufen werden und vom Code dieses Befehles aus müßten die einzelnen Befehle an OS_CLI übergeben werden (dabei müßte auch noch achtgegeben werden, daß der Befehl Obey die Abarbeitung beendet — auch als Teil einer If...Then-Zeile). Darüber hinaus würde MyMenu’s eigener Wimpslot ausgeblendet, so daß das Menü, wenn es nur bei Bedarf geladen wird, immer wieder in die RMA geladen werden müßte (zumindest unter RISC OS 3.11, wo es keine Dynamic Areas gibt), was zu RMA-Fragmentation führen würde. Alles in allem viel zuviel Aufwand...
• Die Unterschiede zwischen Obey- und Desktop-Dateien führen dazu, daß z.B. WimpSlot nicht funktioniert (sobald der Befehl abgearbeitet worden ist, wird der Slot wieder auf die Größe von „Next“ gesetzt), ebensowenig kann man eine Applikation mit einem Befehl laden und mit dem nächsten starten — diese beiden Dinge müssen mit einem Befehl geschehen. Alle Befehle, die nichts mit dem aktuellen Slot machen, haben die erwünschte Wirkung.
• Eine Eigenart von Wimp_StartTask führt dazu, daß die Abarbeitung der *commands auch nach einem Fehler fortgesetzt wird. (Das läßt sich leider nicht verhindern, denn alle Fehlermeldungen werden schon innerhalb von Wimp_StartTask ausgegeben und nicht an MyMenu übermittelt.)
Diejenigen *commands, die für MyMenu am nützlichsten sind, werden weiter unten in dieser Datei beschrieben.
Beim Erstellen der *commands einer Menü-Datei müßte man normalerweise die Pfadnamen sehr vieler Dateien und Applikationen von Hand eintippen. Da dies äußerst zeitaufwendig sein kann (außerdem vertippt man sich leicht), habe ich eine Mini-Applikation namens „TypeName“ geschrieben, die einem die Arbeit abnimmt. Sie wird ebenfalls weiter unten beschrieben.
2.2.5. Zusätze
--------------
Die Beschreibung der Befehle zur Definition von Menüs und Menüeinträgen ist noch nicht ganz komplett: An sie kann man nach dem letzten * noch einen oder mehrere ‘Kurz-Befehle’ anhängen, z.B. so:
**MyMenu*Menü*K5E71;L
An die Zeile wurden zwei Zusätze angehängt, die durch ein ; getrennt wurden: Ein „K“-Zusatz (mit nachfolgendem Parameter) und ein „L“-Zusatz. Insgesamt gibt es vier verschiedene Zusätze („B“, „K“, „L“ und „M“), die im folgenden beschrieben werden.
„B“-Zusatz (wie ‘buffer’)
Dieser Zusatz kann sowohl hinter Menü- als auch hinter Menüeintrags-Definitionen stehen. Allerdings bewirkt er hinter einer Menüdefinition nichts anderes, als daß bis zur nächsten Menüdefinition hin alle nachfolgenden Menüeinträge so behandelt werden, als würden sie von einem „B“-Zusatz gefolgt, und es wird ignoriert, ob dieser tatsächlich vorhanden ist. (Damit spart man sich die Tipparbeit, hinter jedem einzelnen Eintrag das „B“ anzufügen.)
Der „B“-Zusatz legt fest, wie mit den *commands des jeweiligen Eintrags (bzw. den *commands aller Einträge des Menüs) verfahren wird. Falls er vorhanden ist, werden die *commands in die Datei „MenuScan“ mit aufgenommen (sie werden somit jedesmal geladen, wenn auch das Menü geladen wird), falls nicht, enthält „MenuScan“ lediglich die Information, wo die *commands in der Menü-Datei „Menu“ zu finden sind. Die Wirkung des Zusatzes ist es also, die Dateigröße von „MenuScan“ zu vergrößern (bzw. zu vermindern, wenn er nicht da ist); wird er bei allen Einträgen verwendet, steigt die Dateigröße auf das doppelte bis dreifache an. Wird er dagegen nicht verwendet, ist ein zusätzlicher Dateizugriff auf „Menu“ nötig, bevor die *commands ausgeführt werden können (und dies ist nicht zu empfehlen, wenn „Menu“ von Diskette oder über ein Netzwerk geladen werden muß). Ob die Verwendung letztendlich nützlich ist oder nicht, hängt in erster Linie davon ab, ob „LoadOnDemand“ verwendet wird:
• Wird es verwendet, sollte man „BufferAll“ dazu benutzen, alle *commands in „MenuScan“ aufzunehmen. Das läßt die Dateigröße zwar anwachsen, aber dies hat ja keinen Einfluß auf den Speicherverbrauch, weil die Daten nicht andauernd im Speicher bleiben.
• Verwendest du „LoadOnDemand nicht“, mußt du selbst entscheiden, ob du wenig bzw. keine Zugriffe auf Files, dafür aber hÖheren Speicherverbrauch willst („B“-Zusatz vorhanden), oder ob du zwar das Menü jederzeit ohne Verzögerung bei nur wenig Speicherverbrauch öffnen kannst, aber beim Anklicken von Menüeinträgen ein Dateizugriff nötig ist („B“-Zusatz nicht vorhanden). Wie immer ist natürlich ein Kompromiß das beste...
Du wirst dich jetzt vielleicht fragen, was ich für ein ‘Speicherplatz-Verbrauchs-Fanatiker’ bin, denn was sind schon die 20 kByte, die MyMenu bei einem etwas größeren Menü verbraucht? Na ja, ich hasse einfach diese Utilities und Programme, die man in die Boot-Sequenz aufnimmt und die jedes ihre paar -zig kByte benötigen, bis alle zusammen auf einmal ein halbes Megabyte oder mehr ausmachen...
„K“-Zusatz (wie ‘Key’)
Mit diesem Zusatz werden die Hotkeys definiert. Er ist der einzige, der von einem Parameter gefolgt wird. Dieser Parameter ist entweder 2, 4, 6 oder 8 Zeichen lang; für jeden der bis zu vier Hotkeys zwei Zeichen. Normalerweise brauchst du dir über diese zwei Zeichen (eine hexadezimale Zahl) keine Gedanken zu machen — benutze einfach das Programm TypeName: Klicke auf den „K“-Knopf oben rechts und drücke eine Tastenkombination. Sobald die Tasten wieder losgelassen werden, tippt TypeName den entsprechenden „K“-Zusatz in deinen Texteditor.
Intern werden die Mausknöpfe genauso wie Tasten behandelt, so daß du z.B. auch ‘Alt MENÜ’ als Hotkey definieren kannst, um ein Menü von MyMenu öffnen zu lassen.
Wird der „K“-Zusatz an eine Menü-Definition angehängt, bewirkt dies, daß beim Drücken der Hotkeys das Menü geöffnet wird. Bei einem Menüeintrag werden dagegen die *commands dieses Eintrags ausgeführt.
„L“-Zusatz (wie ‘Line’)
Der „L“-Zusatz erzeugt eine gestrichelte Linie im Menü, und zwar unter demjenigen Menüeintrag, bei dem er angewendet wurde, oder unter dem Menüeintrag, der zu dem durch eine Menüdefinition angegebenen Menü führt, z.B.:
**MyMenu*Menü*
Dies erzeugt eine gestrichelte Linie unter dem Eintrag „Menü“ im Menü „MyMenu“.
„L“-Zusätze, die bewirken würden, daß eine gestrichelte Linie unter dem letzten Eintrag eines Menüs erscheinen würde, werden ignoriert.
„M“-Zusatz (wie ‘MENÜ’)
Der letzte der vier möglichen Zusätze hat die gleiche Wirkung wie ein „K“-Zusatz, nur daß man das jeweilige Menü öffnen kann, indem man MENÜ klickt, während der Mauszeiger am linken Bildschirmrand ist. Das ist ungemein praktisch, weil man nicht noch irgendwelche zusätzlichen Tasten drücken muß.
(Diese Idee wurde natürlich von StrongED ‘geklaut’ — ich bin ein Zap-Benutzer und finde sie sehr gut, so daß ich sie übernommen habe.)
2.3. Nützliche *commands
——————————————————————————
Einige *commands sind beim Erstellen einer Menü-Datei sehr nützlich, so daß sie hier kurz beschrieben werden. Übrigens werden sämtliche *commands im User Guide (oder in einer auf deiner Festplatte gespeicherten Datei) beschrieben!
Im folgenden steht <Pfadname> für den vollen Pfadname einer Datei oder einer Applikation, z.B. „Resources:$.Apps.!Chars“ (einzutippen ohne Anführungszeichen).
Zum Starten von Programmen gibt es mehrere Möglichkeiten. Normalerweise sollten alle Programme mit folgendem Befehl korrekt gestartet werden können:
Run <Pfadname>
Dies kann auch abgekürzt werden zu:
/<Pfadname>
Falls das nicht funktioniert, versuche:
Filer_Run <Pfadname>
Wenn es jetzt immer noch Probleme gibt (z.B. kein Icon auf der Icon bar), schreibe die folgenden zwei Befehle unter die Eintragsdefinition:
Filer_Boot <Pfadname>
Filer_Run <Pfadname>
Will man Dateien und Programme in ArcFS-Archiven ansprechen, muß ArcFS vor dem entsprechenden Befehl geladen werden, da sonst ein Fehler produziert wird. Die folgende Zeile lädt ArcFS, falls es noch nicht im Speicher ist:
RMEnsure ArcFS 0 /<ArcFS$Dir>
Dies setzt allerdings voraus, daß ArcFS schon ‘gesehen’ wurde, d.h. daß ein Verzeichnis, in dem es sich befindet, geöffnet wurde. Wenn das unpraktisch für dich ist, weil du das Verzeichnis immer wieder öffnen mußt (ich empfehle aber, ArcFS automatisch nach jedem Reset booten zu lassen), kannst du den letzten Teil der Zeile abändern, z.B. so:
RMEnsure ArcFS 0 /ADFS::MyDisc.$.!ArcFS
Da einige Befehle (besonders der obige) viele Male in einer Menü-Datei auftauchen, wurde MyMenu mit der Fähigkeit ausgestattet, diese Befehlszeilen zu erkennen und nachfolgende Zeilen durch kurze Hinweise darauf zu ersetzen, wo der Befehl zum ersten Mal aufgetreten ist. Dadurch kann viel Speicherplatz gespart werden. Damit zwei Zeilen als gleich erkannt werden, müssen sie GENAU gleich aussehen, d.h. es wird zwischen Groß- und Kleinbuchstaben unterschieden, auch dürfen keine zusätzlichen Leerzeichen am Anfang oder Ende der Zeile stehen. (Natürlich wird das nur für *commands gemacht, die in „MenuScan“ aufgenommen werden.)
Filer_Boot <Pfadname>
Dieser Befehl bootet die genannte Applikation (wie wenn ein Verzeichnis geöffnet wird, das die Applikation enthält), so daß sie z.B. geladen wird, wenn eine Datei, die sie kennt, doppelgeklickt wird.
Filer_Run <Pfadname>
Filer_Run kann nicht nur zum Starten von Programmen, sondern auch zum ‘Starten’ von Dateien verwendet werden — die Wirkung des Befehls ist dieselbe wie bei einem Doppelklick auf das Icon der Datei. Ist die im Pfadnamen genannte Datei z.B. eine Textdatei, so wird sie durch den Befehl in deinen Texteditor geladen.
Filer_OpenDir <Pfadname>
Mit diesem Befehl kann man Verzeichnisse öffnen.
3. Tips & Tricks
====================
• Es ist möglich, daß Menüeintrags-Definitionen in der Menü-Datei noch vor der ersten Menüdefinition kommen. Diese Einträge tauchen dann in keinem Menü auf, was praktisch ist, wenn man lediglich einen Hotkey definieren will, aber keinen entsprechenden Menüeintrag braucht.
• Man kann auch mehrere völlig voneinander unabhängige Menüs definieren — der erste Menüname nach ** muß ja nicht immer der gleiche sein!
• Bei der Definition von Hotkeys werden die linken und rechten Tasten für Shift, Alt und Strg unterschieden, genau wie die Zifferntasten von denen des separaten Ziffernblocks.
• Einem Menü(eintrag) können mehrere Hotkeys zugewiesen werden, so daß man z.B. für ‘Alt Z’ einen Hotkey mit der linken Alt-Taste und einen mit der rechten definieren kann.
• Falls man eigene Mini-Programme oder Obey-Dateien durch *commands ausführen lassen will, kann man diese in das Verzeichnis „!MyMenu.Menu“ kopieren, auf das die Variable „MyMenu$M“ zeigt.
• Menüeinträge, deren Namen bis zu zwölf Zeichen lang sind, sparen Speicherplatz.
• Falls einmal ein von dir definiertes Untermenü nicht in deinem Menü auftaucht, überprüfe, ob du den Namen des Hauptmenüs richtig eingetippt hast.
• Wenn du LoadOnDemand verwendest und das Menü von Festplatte laden läßt, wirst du bemerken, daß die LED der Festplatte dabei manchmal gar nicht aufleuchtet. Das liegt daran, daß ADFS einen Zwischenspeicher benutzt, der normalerweise größer als „MenuScan“ ist, so daß diese Datei nicht jedesmal wirklich neu geladen werden muß. Allerdings wird der Inhalt des Zwischenspeichers (evtl. nur teilweise) wieder vergessen, sobald irgendeine andere Datei geladen wird.
• Beim Erscheinen der Fehlermeldung „Error when reading XXX — directory XXX not found“ (natürlich mit einem Verzeichnisnamen statt „XXX“) sollte eine Datei aus einem Archiv heraus geladen werden, aber ArcFS war nicht geladen.
4. Bekannte Probleme
========================
• MyMenu arbeitet nicht mit dem Modul CDKeys zusammen. Daran ist allerdings CDKeys schuld. (Es gibt bei Tastenkombinationen, die es kennt, das ‘key up/down event’ nicht weiter.) Außerdem gibt es noch Probleme mit Reversi von Alex Hopkins (keine Ahnung warum).
• Normalerweise wird beim Drücken von Hotkeys der Tastendruck ‘abgefangen’, um zu verhindern, daß außer MyMenu noch ein weiteres Programm auf den Tastendruck reagiert. Dies ist leider nicht möglich, wenn sich der Cursor in einem ‘Writable icon’ befindet.
• Ich hatte keine Möglichkeit, das Programm auf einem RiscPC mit einem anderen als dem Standard-Keyboard zu testen. Allerdings müßte alles auch mit anderen Keyboards funktionieren. (Einzige Bedingung: Die vom Keyboard übermittelten Codes für die Tasten dürfen nur acht Bit weit sein!)
• Wie gesagt: Nach einem Fehler in einem *command wird mit dem Abarbeiten weiterer *commands fortgefahren — das kann ich nicht ändern.
• Die *commands eines Eintrags dürfen nicht dazu verwendet werden, MyMenu selbst zu beenden oder neu zu starten — das führt zu einem Absturz!!!
• Zwar erlaubt MyMenu als Hotkey bis zu vier gleichzeitig gedrückte Tasten, aber diese Anzahl ist nur erreichbar, wenn unter diesen Tasten Shift, Alt und/oder Strg sind; nach mehr als zwei Buchstaben-/Zifferntasten werden keine weiteren Tasten mehr erkannt (liegt nicht an MyMenu, sondern am Keyboard) ...tut mir leid für die Akrobaten unter euch!
• MyMenu selbst macht bei der erlaubten Verschachtelungstiefe von Menüs keine Einschränkungen, allerdings läßt das Betriebssystem nicht mehr als sieben Untermenü-Ebenen zu, d.h. zu keinem Zeitpunkt dürfen mehr als acht Menü-Fensterchen auf dem Bildschirm sein. Das dürfte aber auch mehr als genug sein.
5. Die Applikation „TypeName“
=================================
TypeName ist eine kleine Applikation, die das Erstellen der Menü-Datei erleichtert, indem sie dir das Eintippen von Datei-/Verzeichnispfaden, „K“-Zusätzen und anderen häufig gebrauchten Zeichenketten abnimmt.
Nach dem Starten öffnet das Programm ein Fenster. Es gibt kein Icon auf der Icon bar — indem man das Fenster schließt, beendet man TypeName.
Zieht man auf das Fenster eine Datei oder ein Verzeichnis, wird der jeweilige Pfadname „eingetippt“, so, als hätte man ihn auf der Tastatur getippt. Wenn dies geschieht, muß der Cursor natürlich gerade in einem Texteditor o.ä. sein, damit es von Nutzen sein kann. Zusätzlich tippt das Programm auch noch beliebige Zeichenketten ein, die vorher in die drei Eingabe-Icons geschrieben wurden, wenn man auf ‘Tippen’ rechts vom jeweiligen Icon klickt. „K“-Zusätze werden eingetippt, nachdem man auf „K“ rechts oben geklickt und die gewünschten Tasten gedrückt sowie wieder losgelassen hat.
Versucht man, etwas eintippen zu lassen, während der Cursor gerade in TypeNames eigenem Fenster ist, wird eine Fehlermeldung ausgegeben.
[ Hinweis in letzter Minute: Zu meiner überaus großen Freude habe ich gerade festgestellt, daß Zap, StrongED und Edit Pfadnamen eintippen, wenn man das Dateisymbol mit Shift auf ihr Fenster zieht - Aaaarghh! ]
